To ensure data security and service continuity, it is generally required to establish a disaster recovery data center at a remote location from an active data center, for disaster recovery of the active data center. When a fault occurs in the active data center because of a natural disaster or the like, the remote disaster recovery data center can directly take over a service of the active data center. In actual applications, the following problem needs to be resolved: how a system can quickly switch a client's destination access address from a server A of the active data center to a server B of the remote disaster recovery data center when a fault occurs on the server A.
One existing solution is a domain name system (DNS) solution. A correspondence between an IP address and a domain name of each virtual machine (VM) is registered on a DNS server. The DNS server detects and updates a status of each virtual machine in real time. When a fault occurs on a virtual machine A in an active data center, a client needs to re-initiate a connection request to the DNS server. The DNS server returns an IP address corresponding to a domain name of a virtual machine B in a disaster recovery data center to the client. The client initiates a session connection to the virtual machine B by using the IP address provided by the DNS server.
Because the quantity of domain names that a DNS server can accommodate is limited, the DNS solution cannot support a massive number of services and it does not have a good expansibility. In addition, for a TCP (Transmission Control Protocol) connection, when a fault occurs at an active site, the quintuple (source IP address, source port, destination IP address, destination port, and TCP protocol), which determines an original TCP connection, changes. This results in a damage of the original connection relationship. A user device needs to re-initiate a link request, which will inevitably cause service interruption and affect user experience.
Another existing solution is a LISP (Locator/ID Separation Protocol) solution, which is an IPinIP protocol. In the LISP solution, an IP address of a routing locator (RLOC) and an IP address of an end-point identifier (EID) are distinguished, and they are encapsulated in a stacked manner. When being transmitted on a public network, an encapsulated packet is forwarded according to the routing locator's IP address only. Only when the packet reaches a site boundary, the outer IP address, the routing locator's IP address, is removed, and the inner IP address, the end-point identifier's IP address, is used for forwarding. However, according to the LISP solution, after a virtual machine is migrated, an ingress tunnel router (ITR) cannot be notified to quickly switch to a new routing locator's IP address. When a virtual machine is just migrated from a site A to a site B, an ITR of the original site A does not know about a new routing locator's IP address, and still uses an original routing locator's IP address as a destination routing locator's IP address for packet encapsulation and sending, which causes service interruption. Connection is re-established and service is restored only after the ITR acquires the new destination routing locator's IP address. In addition, the LISP solution brings a delay problem when an EID is registered to an egress tunnel router (ETR) of the new site B after the virtual machine is migrated. After the virtual machine is migrated, the ETR of the new site B knows that the ETR needs to release a corresponding EID externally and perform registration by using a map server (MS) only when the ETR learns through listening that this IP packet whose address segment is a source IP address appears locally. Therefore, an entire registration process cannot be completed in a timely manner.